Computer systems, and more specifically networked computer systems are a center point of modern society. Advances in production and miniaturization have permitted the production of increasingly faster processors and larger data storage.
Commerce, and indeed business in general is highly reliant on networked computer systems for nearly all aspects of business activity, such as but not limited to offering products for sale, maintaining account records, analyzing data, etc. . . . Yet, the needs for resources may and often do change from time to time.
Networks exist in a variety of forms, from the vast and expansive nature of the Internet to the small local area network of a company or home setting. Whereas it was once commonplace to provide all desired computer resources within one physical system, networking systems permit a greater flexibility in adaptively balancing resources and scaling to meet needs. Network connection and integration requires an ability for the elements, e.g. systems, of the intended network to find and communicate with each other.
The Open System Interconnection model, also referred to as the Open Source Interconnection model or more simply the OSI model, is a product of the Open System Interconnection effort at the International Organization for Standardization, and more specifically is a prescription of characterizing and standardizing the functions of a communication system in terms of seven abstraction layers of concentric organization—Layer 1 the physical layer, Layer 2 the data link layer, Layer 3 the network layer, Layer 4 the transport layer, Layer 5 the session layer, Layer 6 the presentation layer, and Layer 7 the application layer.
Each layer is generally known as an N Layer. At each layer, two entities, i.e., N-entity peers, interact by means of the N protocol by transmitting protocol data units or “PDU”. A Service Data Unit “SDU” is a specific unit of data that has been passed down from one layer to another, and for which the lower layer has not yet encapsulated into a PDU. Moreover the PDU of any given layer, Layer N, is the SDU of the layer below, layer N−1. In other words, the SDU is the payload of a given PDU.
Transfer of an SDU between layers is therefore a matter of encapsulation and is performed by the lower layer in adding appropriate headers and or footers to the SDU such that it becomes a PDU. These headers and or footers are part of the communication process permitting data to get from a source to a destination within any network.
Briefly, Layer 1, the physical layer defines the electrical and physical specifications of the device and the communication medium, e.g., copper cable, optical cable, wireless, etc. Layer 2, the data link layer, provides the functional and procedural means to transfer data from one entity to another, and to possibly correct errors that may occur in the physical layer. The data is arranged in logical sequences known as frames.
Layer 3 is the network layer and provides the functional and procedural means of transferring variable length data sequences from a source on one network to a destination host on a different network. Routers operate at this layer and make the Internet possible by properly handling the interconnections and handoffs between different networks. Layer 4 is the transport layer responsible for data transfer between end users and the reliability of a given link through flow control, segmentation/desegmentation and error control.
Layers 5, 6 and 7 as the Session, Presentation and Application layer are successively higher and closer to the user and subsequently further and further away from the physical layer. The greater the number of transfers between layers to accomplish any given task, the greater the complexity, latency and general opportunity for error.
Indeed within a typical local area network (LAN), wherein the systems are indeed part of the same network, the communication of data transfer is generally accomplished at the Layer 2 level. However, when joining one LAN to another, or to a wide area network (WAN), the addresses of the LAN may be meaningless or perhaps even duplicative of other addresses in other LANs and as such the translation to Layer 3 is the generally accepted method for maintaining harmony in communication.
While this is a viable option, and indeed the existence of the Internet demonstrates overall functionality, it does often come with overhead costs and burdens of complexity. For example, whereas a database within a LAN may be communicated with via Layer 2 and thereby enjoy enhanced integration as a networked component, accessing a similar database over Layer 3 requires Internet Protocol “IP” address translation, or other similar transformation which by it's vary nature requires the originating system to be configured for, and perhaps engage in appropriate measures for proper identification, and addressing of data to and from the remote database as would not be otherwise required with a LAN based database. For example the LAN systems may be on one network or VLAN and the remote database is part of another network or VLAN—the differences requiring at the very least a router to adjust and account for the differences in network identity and configuration.
Indeed, while remote services do provide a lower cost option to the direct acquisition of hardware and thereby permit enhanced scalability of resources in response to needs, the remote services as offered to a plurality of needy parties are not perceived by each party simply as an extension of his or her existing resources.
One form of remote service is that of cloud computing, wherein a collection of physical systems provide both physical and virtualized resources. Although gaining in popularity, cloud computing and the integration of these resources is performed at Layer 3 so as to permit the generally accepted methodologies of IP protocol translations to insure proper segregation of data.
Moreover, as many LANs are configured with default options it is very common for multiple end users to have the same local IP addresses within their various networks. For connection to and utilization of a traditional cloud environment network address translation must be employed—a requirement that is often beyond the skills and capability of the end user. When the needs for such resources are dynamic, such continual adjustments and additions through Layer 3 IP addresses can be taxing in terms of time, costs, and possible error among other factors.
Further, the resources of a cloud environment are also generally limited due to one or more physical constraints. Although perhaps expandable to a point, such expansion cannot generally be achieved in real time as at some point additional physical systems must be installed, configured and integrated. And again, once such systems have been integrated, if the need for resources diminishes they cannot easily be taken out of use without again physical interaction.
With respect to the issue of storage in a multi-tenant cloud environment, the variety of different networking schemes can be an issue. Clients located in the cloud or in adjacent clouds can, and often do, have highly overlapping network configurations. In addition, for purposes of providing scalability, redundancy and operational resiliency, traditional overlapping network issues may be exacerbated as storage solutions have traditionally been provided at OSI Layer 3.
The issue of redundancy and resiliency may benefit from further comment—storage of data is quite important, but hardware devices do fail and or require maintained, replacement and upgrade from time to time. At least two factors are therefore at issue—it is highly desirable not to lose data, and the data must be available when needed.
In order to protect against disaster scenarios, client systems with storage arrays often desire to replicate storage between storage targets—and often in different physical locations. There is an operational challenge in failing over between storage targets in the case of failures that are simplified for client systems if the redundancy is handled transparently—which is highly desired from the client's point of view.
Traditionally, storage arrays provide virtualization functionality where subsets of resources of the storage array are provided to client systems through the implementation of some form of virtual storage machine. To the client system, this virtualized storage system is desired to act like a dedicated storage array, or at least in a manner consistent with a dedicated storage array. Those skilled in the art will understand and appreciate that although virtualized storage systems may be desired in some embodiments, physical storage systems in place of virtualized storage systems, and or a mix of physical storage and virtual storage systems may be implemented without departing from the scope of the present invention.
Presently, the traditional virtualized storage systems cannot transparently handle the wide range of possibilities in overlapping network configurations.
Moreover, although cloud computing does provide an improvement in many ways over previous options for expansion and contraction of resources to meet needs, it is not without it's own set of challenges and difficulties.
It is to innovations related to this subject matter that the claimed invention is generally directed.